5.3.3 APPX Application Design Manual

+ Chapter 1-1: Overview of Application Design
+ Chapter 1-2: Getting Started
+ Chapter 1-3: Data Dictionary
+ Chapter 1-4: Understanding Process Design
+ Chapter 1-5: Interprocess Communication
+ Chapter 1-6: Customizing Your Application
+ Chapter 1-7: The Documentation Facility
+ Chapter 1-8: Application Design Tools
+ Chapter 2-1: Data Dictionary Overview
+ Chapter 2-2: Data Dictionary Concepts
+ Chapter 2-3: Domains
+ Chapter 2-4: Files and Fields
+ Chapter 2-5: Work Fields
+ Chapter 3-1: Overview of APPX Processes
- Chapter 3-2: Getting Started
+ Chapter 3-3: Process Definition
+ Chapter 3-4: Menu Processes
+ Chapter 3-5: Job Processes
+ Chapter 3-6: Input Processes
+ Chapter 3-7: Output Processes
+ Chapter 3-8: Update Processes
+ Chapter 3-9: Query Processes
+ Chapter 3-10: Inquiry Processes
+ Chapter 3-11: Status Processes
+ Chapter 3-12: Subroutine Processes
+ Chapter 3-13: Table Processes
+ Chapter 3-14: Automatic and Optional Children
+ Chapter 3-15: Using the Image Editor
+ Chapter 3-16: Using GUI Features of the Image Editor
+ Chapter 3-17: Using Event Points
+ Chapter 4-1: ILF Integration
+ Chapter 4-2: True/False Status Indicators
+ Chapter 4-3: Specifying Statements
+ Chapter 4-4: The ILF Editor
+ Chapter 4-5: The Appx ILF Debugger
+ Chapter 4-6: ILF Keyword Reference
+ Chapter 4-7: Predefined Fields
+ Chapter 4-8: Runtime Subroutine's and Predefined Processes
+ Chapter 4-9: Appx Chart Director API

Chapter 3-2: Getting Started

Saving Executable Modules


An executable module (EM) is the end result of compiling a process. It is the APPX-executable format that is generated by the process compiler, and accessed by the process loader and process interpreter to execute the process. A process is automatically verified and compiled by APPX when the process is loaded.

To avoid verifying and compiling a process each time it is loaded, and thereby increase performance, you can elect to save an EM on disk. Once an EM is compiled and saved, APPX refers to the saved EM during execution. The process loader, however, verifies that the saved EM is current. If changes to application specifications make the EM obsolete, APPX automatically generates a new EM.

Each EM is automatically assigned an eight-character alphanumeric file name. This unique string is never changed. If APPX finds it necessary to recreate an existing EM, the new EM retains the same file name.

You can designate whether or not you want to save EMs at the installation, application, and process levels. You establish installation and application values in system administration. You can optionally override these designations for each individual process in application design. If you leave a process specification blank, the application value is assumed. If both are blank, the installation value is assumed.

There is a cost associated with saving an EM; it consumes disk space. This trade-off must be evaluated based upon the specifics of each installation. As a general rule, however, EMs should be saved for larger processes, because they require significant compile time. For smaller processes that are relatively quick to compile, the consumption of additional disk space may not be warranted.

Refer to Process Definition, for Executable Module -- Save on Disk? specifications.

Application Design Manual                                         "Powered by Appx Software"

287

©2006 By APPX Software, Inc. All Rights Reserved